Reaction Match Options

The Match Options section determines what requests will match this reaction. In other words, it decides which requests this reaction will be executed for.

There are three main match conditions:

1 HTTP method
2 Relative URI
3 SOAP Action
4 The first element of XML payload
5 Script

SOAP Action and First Element matching are not used and hidden for non-XML responses.

If any of the conditions are undefined, it is not used in the match.

All defined conditions must be true for the reaction to match the request.

HTTP Method

To match, the incoming request must use the specified HTTP Method.

Possible HTTP Methods are:

The pseudo-method Any matches any HTTP method and effectively disables this check.

Relative URI

Relative URI is the part of the URI after the service port.

The URI can contain parameters, like in /user/{userId}. The parameter is then placed into the variable userId and be used in scripting. See REST Variable for details.

SOAP Action

SOAPAction is a value that is sent with SOAP requests.

MockMotor supports both the SOAPAction HTTP header (SOAP 1.1) and action component of the Content-Type HTTP header (SOAP 1.2).

First Element of XML Payload

For some SOAP services, the action field is not defined or defined as an empty string for all operations. We then cannot use the SOAPAction condition to select a reaction that fits the operation. However, for such services, the first element under SOAP Body usually has a unique name, and we can use this instead.

For example, for this request

<soapenv:Envelope ...>
   <soapenv:Header/>
   <soapenv:Body>
      <bt:getOfferEligibility>
       ...

We can configure the reaction to match the first element of the payload when it equals to getOfferEligibility:

Note that SOAP Envelope elements (body, header) are not considered a part of the payload.

The same match will also work for plain XML requests, where the SOAP Envelope doesn’t exist:

<bt:getOfferEligibility>
       ...
</bt:getOfferEligibility>

Script

A match by a script allows fine-grained access to any property of the incoming request.

The scripting language can be either Javascript or XQuery and is configured in the reaction’s General Properties. Javascript-based reaction can also use JSONPath.

The most common types of match by script include (but are not limited to):

Match by Particular Request Value

Sometimes, we only need to match requests with a particular value in the payload. For instance, we may have different reactions for two different consuming applications that are identified by their codes in the request.

Then, we can limit our reaction to a specific consumer by adding a match by a script:

XML

We can use an XQuery expression that resolves into either boolean or into a non-empty sequence. For example, the following script checks that the request comes from an application named “Online”: $input//*:ApplicationID='Online':

The $input variable contains the request. See Payload Variable for details.

Javascript

For Javascript, we will have to provide the full path to the value, e.g. input.GetOffers.Header.ApplicationID=='Online'. The expression must resolve into a boolean true to match.

JSONPath

JSONPath is an improvement for Javascript matching. We should only specify the path: $..ApplicationID=='Online'.

Match by HTTP Header

We can match the request based on the request HTTP header (or lack thereof).

For instance, we can simulate HTTP Authentication exchange by rejecting any request that comes in without Authorization HTTP header and send back an HTTP status 401 (Unauthorized):

The headers are provided in the $http (http for Javascript) variable. See HTTP Variable for details.

Match by Query String

A value passed in the URL query string can also be used for a match. The input parameters are parsed into the $http (or http for Javascript) variable. See HTTP Variable for details.

For example, imagine a reporting service where the response format can differ based on the CALL_TYPE parameter:

/report?CALL_TYPE=3&PHONE_NUMBER=18002221234

The reaction can be configured to match format type 3 with the following expression (for a Javascript-based reaction):

Match by URL Component

For REST services, a URL component can be a value that needs to be matched against.

Imagine a REST service where a URI component is defined as a variable:

/SwaggerPetstore/v2/pet/1000

Then, we can match the reaction by the value that is passed in the URL, e.g. here, we only match if that value is 1000:

Note that you can also use the simplified variable petId.

Match by Account Value

Sometimes users want to mark accounts as belonging to a specific flow - some reactions should only match accounts in one flow.

To achieve this we can match the request by the account values that it would use:

Note that this case is special.

First, MockMotor matches the request by the HTTP Method and first element of the payload (GetAccountDetails), i.e. performs the checks in its normal order.

Then, however, it sees that the matching script contains a reference to the account variable $account. To have the value of the $account, MockMotor first performs the account selection, finding the account that has the ban property matching the value from the request using the XPath $input//*:BAN.

Only when this account is found and loaded, MockMotor executes the matching script, checking that the account’s property type has the value MobilityOnly.

If the selected account has a different type, the reaction is considered to be not matching, and the next reaction in the list is tried.